Method for protecting computer programs and data from hostile code

ABSTRACT

A method that protects computer data from untrusted programs. Each computer&#39;s object and process is assigned with trust attributes, which define the way it can interact with other objects within the system. When an object is classified as untrusted, it can interact with other object within the system on a limited basis. A virtualized system is provided on the computer so that when the untrusted object attempts to perform an operation that is outside its scope of authorization, the virtualized system intercepts the operation but present the untrusted program with an indication that the requested operation has been performed. The method further includes processes to securely move a program from an untrusted group to a trusted group.

RELATED APPLICATIONS

This application claims priority from, and is a Divisional of U.S. Ser.No. 13/316,442, filed on Dec. 9, 2011, which is a Continuation of U.S.Ser. No. 12/553,084, filed on Sep. 2, 2009, which is a Continuation ofU.S. Ser. No. 11/141,909, filed on Jun. 2, 2005, which is a Continuationin Part of, U.S. Ser. No. 10/037,560, filed Jan. 4, 2002, and whichclaims priority from Provisional Application Ser. No. 60/683,211, filedMay 23, 2005.

FIELD OF THE INVENTION

The invention relates to a method for protecting computer data andprograms, and more generally to computer system and network security.The invention is useful for preventing data damage and theft, which canbe done by malicious code attacks.

BACKGROUND

A computer in the present specification is a machine containing aprocessor and memory, and where the processor is able to executeinstructions selected among a given set of instructions. A series ofinstructions for execution by the processor is called a “program” or“code.” When stored in the memory of the computer, a program is referredto as “passive code.” When loaded into the processor for execution, itis called a “process.” Data is information that may be handled ormanaged in any way by a computer program; data may also be stored in thememory of the computer. A network comprises a plurality of computersconnected together.

We call “malicious” or “hostile” any code designed or modified tointentionally corrupt or steal data or programs from the computer systemor network on which it runs. Protecting from hostile code is achallenging problem, since there is no way to programmaticallydistinguish positive and negative program actions, other than knowingwhether they are ultimately good for the user or not. For example, aprogram may delete a file because the user has explicitly asked it to,but a malicious program could also delete a file against the user'swill. In other words, there is no proper technical definition of“malicious” or “hostile” code—these being defined according to thebehavior expected from a computer by its legitimate user.

Although it is possible to authenticate authorized users with password,trusted users themselves may endanger the system and network's securityby unknowingly running programs that contain malicious instructions suchas “viruses,” “Trojan horses,” “malicious macros,” “malicious scripts,”“worms,” “spying programs” and “backdoors.” A computer virus is aprogram that replicates by attaching itself to other programs. A Trojanhorse is a program that in a general way does not do what the userexpects it to do, but instead performs malicious actions such as datadestruction and system corruption. Macros and scripts are programswritten in high-level languages, which can be interpreted and executedby applications such as word processors, in order to automate frequenttasks. Because many macro and script languages require very little or nouser interaction, malicious macros and scripts are often used tointroduce viruses or Trojan horses into the system without user'sapproval. A worm is a program that, like a virus, spreads itself. Butunlike viruses, worms do not infect other host programs and instead sendthemselves to other users via networking means such as electronic mail.Spying programs are a subtype of Trojan horses, secretly installed on avictim computer in order to send out confidential data and passwordsfrom that computer to the person who put them in. A backdoor is a secretfunctionality added to a program in order to allow its authors to crackor misuse it, or in a general way exploit the functionality for theirown interest.

All of the above programs can compromise computer systems and acompany's confidentiality by corrupting data, propagating from one fileto another, or sending confidential data to unauthorized persons, inspite of the user's will.

Along the years, different techniques were created to protect computersystems against malicious programs:

Signature scanners detect viruses by using a pre-defined list of “knownviruses.” They scan each file to for each virus signatures listed intheir known virus database. Each time a new virus is found anywhere inthe world, it is added to that database. However, today more and morenew viruses are created every day, and the known-viruses list needs tobe constantly updated in order to be effective. Regularly updating ananti-virus is a heavy task for both the single-user and the networkadministrator and it leaves an important security gap between updates.

Another detection method, commonly called Heuristic Scanning consists ofscanning programs for suspicious instructions that are typical tomalicious programs and specifically viruses, without needing to have anexact signature of each virus in order to detect it in files. However,malicious program writers can avoid or hide those typical instructionsby writing their code differently and/or encrypting it and thusmalicious code and viruses rapidly avoid detection by HeuristicScanners.

U.S. Pat. No. 5,408,642 and U.S. Pat. No. 5,349,655, issued to Mann andU.S. Pat. No. 5,613,002, issued to Kephart et al., all disclose methodsfor recovering a computer program infected with a virus. The disclosedmethods include generating fingerprint of data prior to infection by avirus and storing the fingerprint. Second fingerprint of data is thengenerated and compared to the prior strings of data, to determine if thedata has been corrupted by a virus and for restoring the data to itsinitial state. These techniques do not prevent viruses from infecting,nor do they protect against other types of malicious programs.

U.S. Pat. No. 6,073,239, issued to the present inventor, discloses amethod where file I/O activity is filtered. Whenever a program attemptsto infect or inject code into another program file, it will be denied.The method, however, is only designed to work against executable-filesviruses. It does not address other types of viruses, such asmacro-viruses, nor other types of malicious programs: worms, Trojanhorses, backdoors or spying software, because these malicious programsdo not inject code nor modify other programs, but directly triggermalicious actions such as data corruption.

U.S. Pat. No. 5,421,006, issued to Jablon et al., discloses a method forassessing integrity of computer system software at time of systeminitialization. Startup processes are verified before being allowed toexecute. The method, however, does not prevent the protected processesfrom being corrupted in the first place, nor does it deal with data andprograms other than those related to the system startup.

Other security methods consist of certifying programs that areauthorized to run and blocking out all the other, unauthorized programs.Unfortunately, these techniques are not always adapted to open systemswhere users receive and exchange many files.

One common security system consists of establishing access control lists(i.e. ACL, DACL) that define restrictions and rights as to which usersare allowed or not allowed to access certain resources, based on thoseusers' rights. For example, system administrators are typically allowedto modify any files while simple users cannot read nor modify someconfidential or critical files. Such security system is usuallyintegrated in modern operating systems to ensure data security andconfidentiality on a per-user basis. However, it is important to make adistinction and understand that this security scheme was designed toaddress the issue of user trust, not the issue of code trust. Users whorun malicious programs within their systems will unknowingly compromisethe integrity of every resource and file they're allowed to access withno further protection. For instance, let's say user X is granted fullaccess to the shared files A, B and C. If this user runs a programinfected with a virus, the virus will be able to read, infect or evendestroy the files A, B and C. This is due to the fact that accesscontrol lists are designed so that programs and tasks run in thesecurity contexts of the users who started them. Thus, even though theuser has not meant to actually harm files A, B and C, the program he randid harm these files despite of the user's will, yet accordingly to theuser's rights. This is the heart of the malicious code problem. If auser runs hostile code, the code will be able to corrupt and steal anydata within the system or network to which its user has access. And if asystem administrator runs hostile code, the entire system and networkare immediately compromised. Also, additionally to these securityproblems, access control lists are statically defined for each file andresource. In environments where files are shared and exchanged everyday, this does not provide enough security against malicious code, sinceusers usually don't take the time to assign the right securityattributes for each new file they create or receive. Such systems aredisclosed in EP-A-0 472 487, or in the article of Moffett J. et al,Specifying Discretionary Access Control Policy for Distributed Systems,Computer Communications vol. 13 no. 9 pp. 571-580.

“Sandboxing” techniques allow testing suspicious programs by safelyrunning them in a secure “sandbox” environment without letting thetested program harm the system or its files. Malicious programs,however, may not perform the offensive or expected actions immediatelyduring the test period, either because they detected that they're beingtested, or because they're designed to perform their offensive actionsrandomly or at certain dates, for example. Hence, although a programseems to behave correctly during the test period, it can harm the systemonce it has passed the test and has been allowed to run for real. Also,positive programs may not behave correctly or not function at all withina sandbox, as they may need to access files and resources within thesystem for normal reasons.

U.S. Pat. No. 5,398,196, to Chambers, discloses a method for emulating aprogram's execution in a virtual process, while searching for viralbehavior. The disadvantages of this method are the same as above.

SUMMARY

The invention provides a solution for protecting data and programpresent on a computer from hostile code. It offers protection at anystage of operation of the computer, and protects the computer from anytype of hostile code. Specifically, the invention provides a process forprotecting objects in a computer from hostile code, comprising the stepsof:

defining at least two trust groups;

assigning objects and processes in the computer to one of said trustgroups, irrespective of the rights of a user of said computer;

upon operation of a process over an object or over a second process,comparing a trust group of the process with a trust group of the objector with the trust group of the second process, and

allowing the operation according to the results of said comparing step.

In an embodiment, a process is assigned, upon it being created, to thetrust group assigned to the passive code from which the process iscreated. One may also provide a step of changing the trust group of theprocess and/or of the object after said operation. One solution thereforis to assign the process to the trust group of the object or of thesecond process, when the operation is allowed.

The process may further comprise, upon creation of an object by aprocess, the step of assigning said created object to the trust group ofsaid process.

In a preferred embodiment, trust groups are hierarchically ordered, andthe step of allowing comprises:

allowing said operation when the trust group of said process is higherin said hierarchy than the trust group of said object or of said secondprocess or equal to the trust group of said object or of said secondprocess, and

denying said operation when the trust group of said process is lower insaid hierarchy than the trust group of said object or of said secondprocess.

One may also provide a step of assigning the process to the trust groupof an object or of a second process after the operation is allowed.

There may also be defined at least two types of objects, objects beingassigned to one of said types; the step of allowing operation over anobject may then be carried out according to the type of said object. Onemay also define least two types of operations; the step of allowingoperation over of a process being then carried out according to the typeof said process. One may also define at least two types of operations;the step of allowing operation over an object is then carried outaccording to the type of said operation. It is further possible todefine at least two types of storage methods and assign a trust group toa type of storage methods; a storage operation for a process of a trustgroup may then be carried out according to the storage method assignedto the trust group of said process.

The invention further provides a computer, comprising

objects and processes;

a table of at least two trust groups, objects and processes in thecomputer being assigned to one of said trust groups irrespective of therights of a user of said computer;

a controller accessing said table and allowing an operation of a processover an object or over a second process according to the results of acomparison of the trust group of said process and the trust group ofsaid object or of said second process.

The computer may further comprise a table of types of at least two typesof objects, objects in the computer being assigned one type; in thisinstance, the controller accesses said table for allowing an operation.The table of trust groups is preferably stored in a non-volatile memory,as well as the table of types is stored in a non-volatile memory.

The computer may also comprise a table of rules; the controller thenaccesses the table of rules for allowing said operation. It isadvantageous that the table of rules is stored in a non-volatile memory.

Last, the invention provides a computer network, comprising a server andat least one such computer; the table of trust groups is then stored insaid server. It also provides a computer network, comprising a serverand at least one such computer, the table of types is then stored insaid server. It last comprises a computer network, comprising a serverand at least one such computer; the table of rules is then stored in theserver.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features and advantages of the invention will appear from thefollowing description, where

FIG. 1 shows diagrammatically passive code and a process;

FIG. 2 is a flowchart of a process for assigning processes to a trustgroup;

FIG. 3 is a flowchart of a process for assigning new objects to a trustgroup;

FIG. 4 is a schematic view of a computer where the process is embodied;

FIG. 5 is a flowchart of a process according to the invention;

FIG. 6 is a flowchart of an operation of a process over an object; and

FIG. 7 is a flowchart of the application of a rule.

FIG. 8 depicts an embodiment wherein a server communicates withrepository and a network.

FIG. 9 illustrates each of the user computers equipped according toembodiments of the invention, including an operating system envelop.

FIG. 10 depicts an embodiment of the present invention, which isbeneficial for use in system depicted in FIG. 8.

FIG. 11 illustrates another embodiment of the invention.

DETAILED DESCRIPTION

The invention is based on the recognition that the action of hostileprograms in spite of the user's will is due to the fact that programsrun with the same access privileges as the users who executed them.Thus, any object that is accessible to the user, is also accessible tothe programs he runs—and may therefore be accessed by a hostile programin case the user inadvertently or intentionally runs such a program.

The invention thus suggests defining trust groups, and assigning objectsin a computer to one of the trust groups. Any operation of a processover an object is then allowed or denied according to the results of thecomparison of the trusts groups of the process and of the object uponwhich the process operates.

The method of the invention is different from all prior art methodsdiscussed above. There is no need to scan files or programs to detectknown signatures; the process operates independently from the user.Instead of assigning rights to the user and allowing any action of theuser, the invention assigns trust values to the programs and objects inthe computer.

In a computer, we call “code” or “program” any set of instructions thatcan be interpreted or executed by the processor of the computer. Whencode is passively stored on a storage media without being executed, wecall it “passive code.” When code is actively running in memory, it is a“process.” The mechanism of loading a program from the storage mediawhere it resides as passive code, into memory (e.g. RAM) where it runsas an active process, is called “execution.” FIG. 1 illustrates anexample of code execution mechanism: here, a file 2 called “WORD.EXE”represents passive code. This file is stored in a storage device of thecomputer, such as a hard disk. When the computer instructs to executeit, the Operating System (OS) copies an image of this file into memory(RAM) and runs it from there. At this stage, “WORD” is a process 46,since it is now running Note that although the file “WORD.EXE” and theprocess “WORD” that is in memory may have similar contents (because oneis initially copied from the other), they are two different entities:each can be modified without affecting the other. Additionally, thecomputer user can execute “WORD.EXE” several times and have severaldifferent “WORD” processes running at the same time, but separately.Furthermore, processes can execute passive codes and hence create otherprocesses. If a process A creates a process B, process A is called the“parent process” and process B is called a “child process.”

We call “object” any file, passive code, document, script, macro,process, registry key or other system object that needs to be protectedby the present invention, or that contains Code that can be interpretedby the OS or any Process. An object containing Code is preferablyprotected, since it may be executed, and may therefore be used forhostile purposes.

Processes and objects being defined, the process suggest defining trustgroups, and assigning objects and processes to one of the trust groups.A trust group is thus a set of processes and objects. The way objectsand processes are assigned to the trust groups is discussed below; andit should only be noted that the trust groups are independent of therights of the user of the computer. In other words, trust groups aredifferent from the rights defined in the prior art.

For the sake of convenience, trust groups may simply be represented by atrust value common to all elements of the group. This value may berepresented as a number, or by any other representation. In the simplestinstance, two groups are defined. The groups could then be representedby 0 and 1—where one of these values means “trusted” and the other onemeans “untrusted”. As exemplified below, trust values could also be anumber from 0 to 10. This may allow up to 11 trust groups to be defined.For determining objects and processes to one of the trust groups, onemay use a trust table, representative of the trust group of each processor object assigned to one of the trust groups. There may be provided twotables, for storing separately trust groups for objects and processes.Indeed, it is advantageous that the trust table for the objects berecorded on a non-volatile storage device, e.g. a hard disk or a remoteserver; on the other hand, since processes are essentially active in RAMonly, a trust table for processes may be stored in the RAM.

Objects and processes being thus assigned to trust groups, any operationof a process over an object—e.g. for modifying or deleting an existingobject—causes the trust group of the process to be compared to the trustgroup of the object. The operation may then be allowed or not allowedaccording to the results of the comparing step.

The process disclosed above protects objects in the computer fromhostile code. Assume for instance two groups are defined, one containing“trusted” objects and processes, the other one containing “untrusted”objects and processes. As explained below, trusted objects and processescould be considered not hostile, e.g. commercial code and the like. Onewould allow or not allow an operation of a process upon an objectdepending on the trust group. For instance, in the simplest embodiment,the only prohibited operations would be the operations of an “untrusted”process over a “trusted” object. This embodiment is crude, and it stillmakes it possible to restrict the operation of the computer so thatthere is no risk of hostile code interacting with the computer. Indeed,such code would be assigned to the “untrusted” group—since its originmay not be identified. As compared to the prior art system of rights,this process also protects the computer from actions of the user. Sinceprocesses and objects are assigned to the trust groups irrespective ofthe user, the user may not endanger the computer, even if he has highlevel rights.

As briefly explained above, one may start by assigning objects tovarious trust groups. Objects may be assigned to the trust groupsaccording to the confidence given to these objects. For instance,software purchased from a computer vendor would normally be more trustedthan software downloaded from unknown Internet Web or FTP sites.Software copied at the installation of a computer may also be consideredas trustful, and may be assigned to a trust group accordingly. Objectsinstalled later would be assigned to a trust group representative of alower trust. Assigning objects to trust group may be carried out by acomputer supervisor. This supervisor is the person who is in charge ofthe computer's security. In a networked environment, this is usually thenetwork administrator. In single-user environments, this can be themachine user.

The same method may be used for assigning processes to trust group. Itis, however, clear that this is likely to be time-consuming and not veryeffective. FIG. 2 therefore shows a flowchart for assigning processes toa trust group. As discussed above, processes are created from passivecode. One solution for assigning a process to a trust group is thereforeto assign this process to the trust group assigned to the passive codestarting from which the process is created. This is shown in FIG. 2 inthe embodiment where trust groups are defined in an object trust tableand in a process trust table. In step 8, passive code is executed, thuscreating a process in RAM. In step 10, the object trust table isconsulted for determining the trust group to which the passive code isassigned. In step 12, the process is assigned to the same trust group.This is marked in the process trust table. The process of FIG. 2 makesit possible to assign simply and rapidly processes to a given trustgroup.

FIG. 3 shows a flowchart for assigning new objects to a trust group.Briefly, a new object is assigned to the same trust group as the processthat created it. In step 20, an existing process, assigned to a giventrust group, creates a new object. In the next step 22, the processtrust table is consulted for determining the trust group to which theprocess is assigned. In step 24, the new object is assigned to the sametrust group. This is marked in the object trust table. The method ofFIG. 3 makes it possible to assign simply and rapidly new objects to agiven trust group. It may not be carried out in every instance. Thus,this method could be carried out under normal use of the computer.Another method would be carried out when new objects are installed onthe computer. One may also allow the supervisor only to use a methoddifferent from the one of FIG. 3 for assigning objects to trust groups.Again, this is different from the prior methods, since the objects areassigned to a trust group, regardless of whoever the user of thecomputer is. In other words, once an object is assigned to a trustgroup, this assignment of the object applies for any future user, be itthe supervisor or another user.

In one specific embodiment of the invention, one may refine the rulesfor allowing operations. As discussed above, operation of a process overan object may be allowed on the sole basis of the comparison of thetrust groups. One may also define different types of objects, operationsor processes. An operation would then be allowed or carried out takinginto account the type of object, operation, process or storage method.For objects, one could for instance distinguish between passive code andother objects, and allow different operations according to the type ofobjects. This allows providing further protection to certain types ofobjects. For processes, one could distinguish between processesaccording to user-defined process types. For operations, one coulddistinguish between opening, reading, creating, modifying or deleting.Again, this makes it possible to makes some operations—e.g. those deemedto be more risky—more difficult to carry out than others. One could alsodefine different storage methods—e.g. using encryption and/orcompression—and assign a trust group to a given storage method. In thiscase, a process in a trust group would use the storage method to whichits trust group is assigned. This makes it possible to use variousstorage methods according to the level of confidence granted to theprocesses. One could thus protect trusted information—informationcreated by a trusted process—by encrypting it.

So far, the description protects a computer against hostile code. It mayhowever interfere too much with the operation of the computer—it beingunderstood that any protection against hostile code will interfere withthe operation of the computer, and will limit the scope of allowedoperation. A more flexible example is now described. In this example,trust groups may be changed, for processes and/or for objects, in casean operation is allowed. This makes it possible to broaden the scope ofoperations, while still protecting the computer. Alternatively, it mayimprove the protection of the computer. An example is given in the caseof two trust groups. The rules for allowing operations could thencomprise the following rules:

allow operation of a process assigned to the “trusted” group over anobject of this group;

allow operation of a process assigned to the “trusted” group over anobject of the “untrusted” group, and assign the process to the“untrusted” group thereafter, with other rules being defined for theother cases. Assume for instance the process is the WORD processdiscussed above. Assume also that this process is in the “trusted”group. The WORD process may access a trusted object, e.g. a trustedfile. When the WORD process accesses some untrusted object, e.g. a newfile downloaded from an Internet server, the operation is allowed.However, the process then passes from the trusted group to the untrustedgroup. This ensures that the process, which may have been corrupted bythe untrusted object, will not contaminate objects in the trusted group.The number of possible operations is increased, while still protectingthe computer; the protection is also improved.

All features discussed above were discussed separately, for the sake ofclarity, one should understand that these features, or some of them onlymay be combined.

FIG. 4 is a schematic view of a computer where the invention is carriedout. The computer 30 comprises non-volatile memory 32, e.g. a harddrive, a floppy disk, or the like. It has a processor 34 with associatedRAM 35. The processor 34 is connected and accesses both non-volatilememory 32 and RAM 35. Memory 32 contains a number of objects 36, as wellas a table 38 of objects trust groups. There is also provided in memory32 a table 40 of types for the objects, as well as a table 42 of rules.RAM 34 contains a number of active processes 44, a table 46 of processestrust groups, as well as a table 47 of types of processes. In addition,there is provided in RAM 32 a controller 48 for accessing the tables oftrust groups when a process is operating over an object. The controllerallows the operation according to the results of a comparison of thetrust group of the process and of the trust group of the object. Thiscontroller may be designed to work at the OS-level, and may beimplemented in a Driver, VxD or TSR, depending on the OS type.

We now provide an example of another embodiment of the invention, wheretrust groups are hierarchically ordered. Such an order makes it simplerto devise rules for allowing or denying operations, upon comparison oftrust groups. Trust groups may then simply be referred to as a trustvalue associated with the group. The words “trust groups” and “trustvalue” are used interchangeably in the rest of this specification. Theorder of the trust groups may for instance be selected as follows: thehigher an object's trust value is, the less accessible and moreprotected it will be, and vice versa. In the example, the trust value isa number from 0 to 10. The objects of a new machine have a high trustvalue. A computer's trust regresses with time, as new software and filesare executed and opened on it. Thus, the computer supervisor willtypically set all objects to a high trust value upon installation of anew machine. Any object installed or introduced later into the computer,will have by default a low trust value, unless the supervisor explicitlyspecifies otherwise (e.g. when installing a new commercial software).

Object Trust Table

Thus, each system's object is initially provided with asupervisor-defined trust value. All of the objects' trust values arerecorded in a “Object Trust Table,” stored on a storage media such as ahard disk or a database server. Any object that is added to the systemwill obviously not be listed in the Object Trust Table as it was setinitially, and thus all objects that are not stored in the Object TrustTable are automatically considered with a low trust value by default.For example, when the machine is in its original clean state, thesupervisor can mark trusted objects with a high trust value. Any objectsreceived from the outside after that moment will automatically beassigned with a low trust value, unless the supervisor specifiesotherwise.

Process Trust Table

Processes, just like objects, are assigned with trust values. Asdiscussed above, Process trust also regresses with time. Indeed, trustedprocesses that load or interpret code can be manipulated into performingmalicious actions themselves. For example, a Process that is initiallyin a trusted state can become hostile in its turn if it opens a filewith macros that instruct it to spy or destroy data. Processes trustvalues will be stored in a second table called “Process Trust Table.”This table is stored in a storage media such as RAM (Random AccessMemory), and can be emptied every time the OS loads-up or restarts,since at that point there are no Processes running. When a Process iscreated during the phase of execution, it obtains the same trust valueas the Passive Code from which it was loaded. For example, if thePassive Code “WORD.EXE” was marked with a trust value of 10, thenwhenever WORD.EXE is executed, the resulting new Process “WORD” will beinitialized with a trust value of 10, too. FIG. 2 shows how a Processobtains a trust value that depends on the object from which it wasloaded.

Creation/Modification of an Object

As explained above in reference to FIG. 3, when a Process creates a newobject, this object obtains the same trust attributes as that Process.When a process modifies the contents of an existing object—upon which itis allowed to operate—the object's trust group is amended to the trustgroup of the process. This makes it possible to take into considerationpossible contamination of an object by a process.

Interaction Between Processes and Objects

FIG. 5 shows a flowchart of the process in the present example.Processes can access objects having the same trust value as themselves.In other words, a Process whose trust value is 5 can access an objectwhose trust value is 5. However, Processes cannot access objects havingtrust values higher than themselves. For example, a Process whose trustvalue is 5 cannot access an object whose trust value is 10.

When a Trusted Process accesses an object with a lower trust value, thetrust value of this Process itself is immediately changed in the ProcessTrust Table and becomes as low as the accessed object's, and thisremains until the Process is terminated. That way, the next time thisProcess attempts to access an object, it will be less privileged thanbefore it accessed the untrusted object. For example, a Process with atrust value of 10 is allowed to access objects whose trust value is 10.But if it opens an object whose trust value is 9, the Process' trustvalue will be lowered to 9 and from that point on it will not be allowedto access objects with trust values higher than 9, and this until theprocess is terminated or restarted. This takes into consideration thefact that a process accessing an object may be contaminated by theobject. Lowering the trust value of the process avoids trusted objectsfrom being contaminated.

FIG. 5 illustrates the way interaction is done between Processes andobjects. In step 50, a Process (P) attempts to access an object (R). Instep 52, we look-up through the Process Trust Table, looking for theentry matching Process P. We store the result in PT. In step 54, welook-up through the Object Trust Table, looking for the entry matchingobject R. We store the result in RT. In step 56, PT is compared with RT.If both trust values are equal, access is allowed in step 58. Back tostep 56, if PT and RT were not equal, we test in step 60 if the Process'trust value is higher than the object's. If this is the case, in step62, the entry for the Process in the Process Trust Table is set to RTand we proceed to step 64 where access to the object is allowed. Notethat the next time Process P attempts to access an object, it will gothrough the same decision-making except that its trust value will bedifferent, as it was changed in step 62. Going back to step 60, if theProcess' trust value is lower than the object's, then we proceed to step66 where access to the object is denied.

Specific Example of the Invention

The following tables provide specific examples of the process indifferent scenarios.

TABLE 1 Actions Performed by the Operations performed by the ProcessTrust Order System controller Value 1 Execution of WORD.EXE whose Markthe newly-created Process 10 trust value is 10. with the same trustvalue as WORD.EXE: 10 2 WORD Process opens object Allow 10 INFO.DOCwhose trust value is 10. 3 WORD Process creates a new Mark thenewly-created object with 10 object: NEWFILE.DOC the same trust value asthe Process': 10. 4 WORD Process opens object Change WORD Process' trustvalue 5 MACRO.DOC, whose trust value in the Process Trust Table to 5 andis 5. Allow access to the object. 5 WORD Process attempts to open Denyaccess to the object. 5 object INFO.DOC, whose trust value is 10. 6 WORDProcess creates a new Mark the newly-created object with 5 object: NEWFILE2.DOC. the same trust value as the Process': 5.

The example of Table 1 shows rules for allowing the operation of theprocess over the object, as discussed in reference to FIG. 5.

TABLE 2 Actions Performed by the Operations Performed by the ProcessTrust Order System Invention Value 1 Execution of an object whose Markthe newly-created Process 1 trust value is 1: VIRUS.EXE with the sametrust value as VIRUS.EXE: 1 2 VIRUS Process Attempts to access Denyaccess to the object. 1 object C:\WINDOWS.EXE whose trust value is 10. 3VIRUS Process creates a new Mark the newly-created object 1 object:PAYLOAD.EXE with the same trust value as the Process': 1.

The example of Table 2 evidences that a low trust process or object maynot contaminate of harm a process having a higher trust value. In theexample of a virus, the virus cannot propagate through the Windowsobject.

Thus, with the method presented so far we have secured the computer,while still allowing a number of operations. We now describe anotherembodiment variant of this method, which is more flexible and faster.

Trust Groups

In addition to providing each object with a trust value, e.g. bydefining trust groups, additional information and behavior is definedfor objects and processes in the groups. Each object and process islinked to a “Trust Group,” using a Trust Group identifier. The followingtable is an example of Process Trust Table where each process,identified by an OS-provided process ID (PID), is linked to a TrustGroup with a Trust Group identifier.

TABLE 3 SYSTEM-DEFINED PID 100 110 120 130 140 TRUST GROUP ID 1 1 2 1 3

Trust Group definitions may be recorded in a central table called “TrustGroups Table,” recorded on a central storage media (e.g. file server,hard-drive or non-volatile memory). Each Trust Group may have a datastructure shown in the following table.

TABLE 4 Trust Group (TG) ID: Trust Group Id TV: trust value FromLower:Rules list ToLower: Rules list

ID is an index value, recorded in the Object Trust Table and the ProcessTrust Table, which identifies the Trust Group to which objects andProcesses belong. TV is the group's trust value. FromLower is a list ofrules to be applied when requests are made by processes whose TrustGroup's trust value is lower than TV, targeted at objects belonging toTG. ToLower is a list of rules to be applied when a process belonging togroup TG is making requests on objects whose trust values are lower thanTV. The following tables are an example of Trust Group definitions, withthree different trust groups.

TABLE 5 Trust Group 1 ID: 1 TV: 8 FromLower rules: A ToLower rules: B

TABLE 6 Trust Group 2 ID: 2 TV: 5 FromLower rules: C ToLower rules: D

TABLE 7 Trust Group 3 ID: 3 TV: 10 FromLower rules: E ToLower rules: F

A “rules list” links several rule nodes together. Each rule node isformed as shown in Table 8.

TABLE 8 Rule (R) OP: Operations TO: Target object types A: Action toperform

OP indicates what kind of I/O operations this rule applies for. Forexample, OP can be: Open, Read, or Write. TO is the type of objects forwhich this rule applies. It can be, for example: executable files,document files and registry keys. Objects can also be applied tofunctions that need to be limited to Processes with certain trustgroups. For example, indicating “networking API” as an object typeforbids use of networking operations to untrusted Processes. A is theaction to perform when OP and TO match a request. It can be for example:“Deny,” “Allow,” “Set requesting process' trust to target object's”and/or “Set target object's trust to process.” These last two actionsallow for dynamically changing a process or an object's trust groups,according to its interaction with other processes and objects. Table 9shows an example of several rules lists.

TABLE 9 Rules A Rules B Rules C Rules D Rules E Rules F Rule #1 Rule #1Rule #1 Rule #1 Rule #1 Rule #1 OP: Read, Write Read Open Open WriteOpen OT: Registry Documents Registry Image files Any file Text filesKeys keys A: Deny Deny Deny Allow Deny Allow Rule #2 Rule #2 Rule #2Rule #2 Rule #2 Rule #2 OP: Open Open Read Open Read Open OT: ImagesExecutables Executables Any file Documents Any file A: Deny Deny AllowDeny Deny Deny . . . . . . . . . . . . . . . . . .

Let us now see how this new implementation works. FIG. 6 illustrates aflowchart in which a process (P) attempts to access an object (O), asshown in step 70. In step 72, we look-up through the Process TrustTable, looking for the entry matching Process P. On most operatingsystems, the process can be identified by its process ID (PID). TheTrust Group ID associated with the process is stored in PTID. In step74, we look-up through the Trust Groups Table, looking for the trustgroup whose ID matches PTID. In steps 76 and 78, we repeat the sameoperations for the object that the process is attempting to access. Instep 76 we look for the object's Trust Group ID within the Object TrustTable and store it in OTID. In step 78 we look-up the Trust Groups Tablefor the Trust Group whose ID matches OTID. In step 80, we compare thetrust value fields of the process' Trust Group to that of the object'sTrust Group. If the process' trust group has a higher trust value, weproceed to step 82, where we apply the rules from the process' trustgroup ToLower field. Back to step 80, if the process' trust group didnot have a higher trust value than the object's, we proceed to step 84,where we test if the process' trust group has a lower trust value. Ifthat is the case, we proceed to step 86, where we apply the rules fromthe target object's FromLower field. Back to step 84, if the process'trust group and the object's trust group had equal trust value fields,then access is allowed to the object in step 88.

FIG. 7 shows how a rule is applied from a trust group's rules listfield. In step 90, we refer to the rules list that needs to be applied.In IOOP, we have the operation that is requested on the target object(O). Steps 92 to 98 are executed in a loop, for each rule node in therules list. In step 96, we test if the current rule's OP field containsthe requested operation IOOP. Such test can be done using a bitcombination for example, where each possible operation is represented bya bit, and the whole number represents the total set of operations. Ifthe test is not positive, we proceed to the next rule in step 92.Similarly, in step 98 we test if the current rule's TO field containsthe type of object O. The object's type can be for example: executablefile, document file, registry key etc. If this is not the case, weproceed to the next rule in step 92. If both conditions were true, theprocess is finished in step 100, where the action to be applied isobtained from the rule node's Action field. If no rule was found thatmatches the required conditions, the process is finished in step 102,where the operation is by default allowed.

To enhance flexibility further, rule nodes can also have a “rulespriority” field. This allows resolving tests between two different trustgroups having the same trust values: the group whose rules priority ishigher, will be obeyed to. This can also help with special cases wherethe rules of the trust group with the lowest trust value needs to beapplied instead of that of the trust group with the highest trust value,as was shown in FIG. 7.

Hence, it is now possible to establish a secure environment in whichseveral Trust Groups protect different objects with different securityattributes. The invention is designed to work at the OS-level, filteringI/O operations. This is usually implemented in a Driver, VxD or TSR,depending on the OS type.

The examples given above may be changed. Trust Groups can be pre-definedand/or configurable. The process may apply to I/O operations as well asAPI function calls or any program-triggered action that may endanger thesystem.

FIG. 8 depicts an embodiment wherein server 800 communicates withrepository 810 and a network 820. Network 820 may be an intranet, aninternet, etc. Various users' computers, e.g., user PC 830-850, are alsoconnected to the network 820. Server 800 can execute various operationsaccording to embodiments of the present invention. Similarly, some orall of the users' computers may execute operations according to variousembodiments of the present invention. Each of the users' computers maystore therein objects that may be assigned a trust value, e.g., trustedor untrusted. When a computer stores objects having various trustvalues, all such object may be stored in the same medium, e.g., the samehard drive, regardless of trust value.

As shown in FIG. 9, each of the users computers equipped according toembodiments of the invention includes an operating system envelope, OSEnvelope 930. When a new program is introduced to the computer, andprior to any part of the program reaching the operating system, the OSenvelope 930 performs a check to determine whether the new programshould be classified as trusted (Trust 910), forbidden (Forbid 920), oruntrusted (Untrust 900). In other words, the OS envelops intercepts allrequests directed to the operating system and determines whether such arequest should be forwarded to the operating system, or whether a checkshould be made for classifying the request as trusted, untrusted, orforbidden.

According to one embodiment of the invention, when a new program isintercepted, the users' computers perform a check to determine whetherthe intercepted new program has been certified by at least onerecognized authority. Such a certifying authority can be, for example, acertifying company such as Verisign, authenticating the origin of asoftware, a software company such as Microsoft, etc. As is known, whensuch a certifying authority certifies a program, it embeds in theprogram a machine-recognizable indication that the program has beencertified and an indication of the certifying authority. Therefore, whenthe OS envelope intercepts a new program, it checks to see whether theprogram includes the certificate and, if so, it classifies the programas trusted and allows the program to install, run, and use all availableresources.

According to another embodiment of the invention, each of the users'computers includes a list of forbidden programs, called black list. Whenthe OS envelope intercepts a new program, it performs a check todetermine whether the intercepted new program is one of the programslisted on the forbidden programs list. If so, the OS envelope classifiesthe new program as forbidden.

According to another embodiment of the invention, when the OS envelopedetermines that the new program cannot be classified as trusted orforbidden, the program is classified as untrusted. According to thisembodiment, when a program is classified as untrusted, it is allowed torun on the computer on a limited basis. In one example, an untrustedprogram is not allowed to access the network 820, and is prevented fromchanging any program or document that has been previously classified astrusted.

According to another embodiment of the invention, when a new program isinstalled on a user computer, a copy of the program is stored in therepository 810. The program is then allowed to run on the user'scomputer on a limited, i.e., untrusted, mode. If at a later time it wasdetermined that the program can be trusted and a user attempts to changethe designation of the untrusted program so as to run the program on anunlimited, i.e., trusted mode, the program is deleted from the user'scomputer and a new copy of the program is installed from the repository810. This is done so as to avoid having a modified untrusted programclassified as trusted. That is, as can be understood, an untrustedprogram cannot change a trusted program, but an untrusted program canchange another untrusted program. So, when program A is classified asuntrusted and is allowed to run on the computer, it can be latermodified by another untrusted program B. However, the user may not knowthat program A was modified by program B, and may try to change thedesignation of program A to be trusted based on its characteristicsbefore the change. If that happens, there is the risk of a userdesignating an infected/modified program A as being trusted. To avoidthat, when the user tries to change the designation to trusted, theoriginal copy of program A is used as the trusted program A.

According to another embodiment, server 800 has a client control programinstalled thereon, and users PC 830-850 have OS envelope 930 installedthereon. Whenever the OS envelope 930 intercepts a new program, itperforms an analysis to determine whether the program is trusted andshould be allowed to run on the computer on an unlimited, trusted, mode.If the results of the analysis show the program to be trusted, the OSenvelope allows the program to install in a trusted mode. On the otherhand, if the analysis is inconclusive, the OS envelope sends theanalysis to the server 800 via the network 820, so that the clientcontrol program can perform an integrity test to verify whether theprogram is trusted and should be allowed to install and run on the usercomputer. If the client control program determines that the program istrusted, it instructs the OS envelope to install the program on the usercomputer.

For example, each of users' computers 830-850 may not have adequatevirus detection program, or may not have updated its virus detectionprogram. Server 800, on the other hand, is run by information technologyspecialists who may have several fully updated virus detection programsinstalled on the server and that are always kept up to date. Therefore,when any of the OS envelopes intercepts a new program, it can send anotice to the client control program on the server 800, and the server800 may perform a virus check on the new program, using the virusdetection programs installed on the server 800. If the result isnegative, i.e., no virus is detected, the client control programnotifies the OS envelope that no virus was detected in the new program.

As explained above, when the OS envelope intercepts an I/O request froman Untrusted programs, it determines if the operation should be allowedor denied. However, as can be appreciated, when the OS envelope deniesthe operation, some applications may generate an error and terminateunexpectedly. In order to allow these programs to run as expected andyet keep the system secured, embodiments of the present inventionprovide a method which virtualizes access to some protected resources.The novel virtualization according to embodiments of the presentinvention consists of making the unsafe program “think” it succeeded inmodifying a protected file or resource, and showing it the resource asif it were modified, but in reality this resource remains unchanged.

According to one embodiment of the inventive virtualization, a nameredirection method is utilized. To understand this embodiment, itsoperation will be described using an example of a program, PROGRAM.EXE,attempting to modify, overwrite, or create a fileC:\ORIGINALDI-RECTORY\DOC.TXT, in a case where the program should not begiven access. Using the name redirection method, the process proceeds asfollows. A copy of the file, DOC.TXT is created on the memory system,e.g., hard drive, in a specially created directory, e.g.,C:\Virtualization\PROGRAM.EXE\DOC.TXT. The program's pending I/Ooperation is then provided to the operating system, but is modified toinclude the new directory, i.e., C: \Virtualization\PROGRAM.EXE\DOC.TXT,rather than the original directory C:\ORIGINALDIRECTORY\DOC.TXT.Consequently, the operating system will perform the requested operationon the copy of the original file and will not modify the original file.Since this operation is done at the operating system kernel level, it isfully transparent to the program requesting the operation. Therefore,the requesting program has no way of knowing that the operation wasperformed on a copy of the file and not on the original file. In thismanner, if the program has attempted to perform a malicious action onthe file, it performed it only on a copy of the file and the originalfile remained unharmed.

Similarly, if the untrusted program attempts to read a file, e.g.,C:\ORIGINALDIRECTORY\DOC.TXT, which may be a trusted file, according tothe inventive method the virtualization directory is first checked tosee whether such a file, i.e. DOC.TXT, exists in the virtualizationdirectory, i.e., C:\Virtualization\PROGRAM.EXE\DOC.TXT. If such a fileexists, the read request is modified to indicate the path to the file inthe virtualization directory and provide the request to the operatingsystem. Consequently, the program reads the virtualized file and not theoriginal file and, any modification previously attempted on the originalfile but actually performed on the virtualized file, are present in theread file and can be viewed by the untrusted program. On the other hand,if the file does not exists in the virtualized directory, the OSenvelope sends the request to the OS to read the original file. If nooriginal file exists, the operation fails.

When an untrusted program requests a deletion of a file, the systemcheck to see whether such a file exists in the virtualization directory.If so, it allows deleting of the virtualized file by modifying therequest to indicate deletion of the virtualized file in the virtualizeddirectory, and the request is provided to the OS for execution.Consequently, the virtualized file will be deleted. On the other hand,if the file does not exist in the virtualized directory, then the systemsimulates its deletion. According to one example for simulating adeletion of a file, the system “flags” the file for itself as beingerased (for example: by listing it in an internal “erased filesdatabase”, or by adding some flags/attributes/streams to it). The fileis not really erased; however, when enumeration request is interceptedby the OS envelope, or when the program tries to access this file in thefuture, the system queries this “erased files database”, and if the fileexists there, the system returns a “Not found” error, as if the file isnot there. The request information is stored in a database or in thevirtual directory.

When an untrusted program requests a renaming of a file, the requestinformation is stored in a database or in the virtualized directory, andthe operation of creating a virtual file as explained above in [0104] isperformed using the new file name.

When an untrusted program performs a call to the operating system toenumerate all files in a directory, i.e., a listing of the directory,the inventive method intercepts the call and returns a reply whichenumerates the combination of the real directory listing, plus thevirtual directory listing, less original files for which the program haspreviously requested deletion or renaming. In this manner, anenumeration call cannot be used to identify that the original files arebeing virtualized.

According to another embodiment of the virtualization, I/O requests tothe operating systems are intercepted and performed by the OS envelopeinto its own database, rather than by the operating system. For example,when the OS envelope intercepts a write operation from an untrustedprogram, it does not send it to the operating system, but rather itwrites the file in its own database. Then, when the untrusted programsends a read request for that file, the OS envelope again interceptsthis request, reads the file from its own database, and sends the fileto the untrusted program. In this manner, the operating system is notperforming any operations for an untrusted program.

According to another embodiment of the invention, a method is providedto ensure that an untrusted program that has been changed to a trustedprogram still operates as a valid program. According to this embodiment,when a user acts to change a designation of an untrusted program into atrusted program, a check point is first made. The check point isbasically an image of the system at the time the request was made. Thenthe request is performed and the program is now allowed to run as atrusted program. However, the activities of the program are monitoredfor any suspicious behavior. For example, if the program tries to modifyan unrelated file, that would be detected as a suspicious activity. Ifsuch a suspicious activity is detected, the user is notified of theactivity and is provided with options to proceed. For example, the usermay stop the operation and close the program. The user may also elect tostop the operation and restore the system using the check point. Thatis, the computer will be restored to its configuration using the imageof the system at the time the check point was made. The user may alsoelect to notify a system administrator and seek the administrator'sadvice. In this case, a notification is sent to an administratoroperating server 800. The administrator may investigate the activity ofthe program and may make a decision to be sent back to the user.

FIG. 10 depicts an embodiment of the present invention, which isbeneficial for use in the system depicted in FIG. 8. That is, theembodiment of FIG. 10 can be advantageously used in conjunction with aclient server 800 having user computers, User PC 830-850, connected toit via a network. The embodiment of FIG. 10 assumes that each of theusers computers is installed with an OS envelope, similar to the OSenvelope described above. The client server is equipped with appropriateprograms to enable the processes described herein-below. The OS envelopeand the client server communicate with each other over the network 820.

When a new file 1000 is intercepted by the OS envelope, the OS envelopecheck to see whether the file is listed on the white list (Step 1010).The White list is a list of programs and files that have been designatedas trusted. If the file is listed on the white list, the OS envelopeallows the file to be installed on the computer 1020 in a trusted mode.That is, the file may perform anything it needs on the computer andinteract with the OS and the network 820. It may also communicate withand change other trusted files and folders. If, on the other hand, thefile is not listed on the white list, the OS envelope checks to seewhether the file is listed on the black list (Step 1030). The black listis a list of programs and files that have been designated as forbidden.If the file is listed on the black list, the OS envelope does not allowthe file to be saved and to access files, on the computer 1020.

If, on the other hand, the file is not on the white list or the blacklist, the file is designated as untrusted and is placed in a buffer zone1035. The buffer zone 1035 is basically an environment wherein the filemay use the computer's resources, but is not allowed to change any fileor folder designated as trusted, and is not allowed to access thenetwork 820. According to one embodiment, this is implemented as avirtualization according to the virtualization method described above.At this point, the user is provided with an option to send a request1040 to the client server. If the user elects not to send the request,the file is allowed to operate in the buffer zone; however, if the filefails to run properly (Step 1050), the user is again provided with theoption of sending a request 1040.

When a user sends a request 1040 to the client server, the file itselfor information about the file is uploaded to the client server over thenetwork. The client server may then perform one or any of the processes:scan, stall, and install (Step 1060). The process of scan is basicallyrunning one or more detection programs to inspect whether the file is orcontains a virus, worm, Trojan, etc. These can be publicly availableprograms, such as McAfee, Norton, etc. As can be understood, theadvantage of having the inventive system is that only one copy of eachscan program needs to be acquired and installed on the client server;thereby avoiding the need to purchase a copy for installation on each ofthe users' computers. In addition to the economic advantage of needingonly a single copy, the inventive arrangement is also more secure. Thatis, as is known, each of the scanner software needs to be periodicallyupdated. However, many users fail to timely update their version of thescanner. Consequently, the scanner may fail to detect a hostile codethat was created after the last update by the user. On the other hands,by having a single copy maintained by a technician at the client server,it is ensured that the latest updates are properly and timely made toprovide maximum security.

If after the scan, or by other means, it has been determined that theprogram can be installed and run on the user's computer, the clientserver upload a version of the file to the user's computer, Step 1070,and adds it to the white list, i.e., enabling it to run in a trustedmode. However, although the file is allowed to run in a trusted mode, itis still monitored and its characteristics and resource usage isreported to the client server, Step 1080. Such a reporting is done fromall of the users' computers and for any programs chosen by the clientserver. The client server displays the reporting on screen 1090 for thetechnician's monitoring. According to one method of the invention, thereporting is generally in the form of a graph, wherein the Y-axisrepresents the resource usage or risk usage of the program; while on theX-axis the various monitored programs are represented. Thus, forexample, bar 1095 represent a high resource usage or high risk presentedby program A, while bar 1096 represent low resource usage or low risk byprogram B. The technician then may click on any of the bars, whereuponthe client server will display the names of all of the computers usingthis program. If the technician determines that the program presents ahigh risk to the users computers, the client servers may remove theprogram from the white list and may disable the program or have it runin an untrusted mode. In this manner, the client server helps monitorthe users computers for malicious code that the user may not be able todetect independently.

It is generally known that malicious code attacks can be detected andpublicized within about 24-48 hours of the first attack. Until then,such new malicious code can infiltrate even computes equipped with themost up to date scanners, since no detection code has been develop forthis new malicious code. Therefore, according to a feature of theinvention, when a request is received by the client server, oneavailable option is stall. According to this option, the client servermay send a notice to the requesting user that the program can be madeavailable only after a given period of time has laps, e.g., 48 hours.The client server then “parks” the new file for the given period to seewhether during this parking period the file will show up as a newlydiscovered malicious code. After the parking period the client servermay scan the file with a newly updated scanner to see whether the filecontains a newly discovered malicious code. If so, the client serverwill disallow this file from running on the users computer and, if not,the client server may allow the file to run on the computer. Anothermethod to combat first day malicious code attacks can be dynamic‘parking’period. Where as it is known that first day malicious codeoutbursts are identified within a few hours. Therefore all requests canbe ‘parked’ for, e.g., 3 hours, ensuring that there is no knownoutbreak. After 3 hours those ‘parked’ requests can be release. Ifhowever an outburst is identified over the network then the systemautomatically curfews all parked requests until a signature is releaseand only after all parked requests are analyzed against the newsignatures the curfew is removed.

If the client server is connected to several users computers and it hasdetermine that a file requested by one of the users computers may beallowed to run, the client server may: 1. allow the file to run on therequesting computer, e.g., by adding the file to the white list anduploading the file to the requesting computer; 2. allow the file to runon the requesting computer and any future requesting computer by addingthe file to all of the users computers white list and uploading theprogram from the server to the originally requesting computer and to anyfuture requesting computer; or 3. allow the file to run on all computersby adding the file to all of the users computers white list anduploading the file to all of the users computers. As can be appreciated,using method 2 provides an added security. First, every time a usercomputer requests to use the file, the client server provides a “clean”version of the file from the client server, and does not allow the useof a version from other sources, as such version may have become“contaminated” with malicious code in the meantime. Secondly, if at alater time it has been determined that the file contains malicious codeor should be removed, then it is necessary to remove it only from therequesting computers. Incidentally, the same procedure may be followedwhen the client server determines that a file may be installed, perParagraph 0110.

Another feature of the embodiment of FIG. 10 related to the request1040. As illustrated by element 1005 in FIG. 10, when the user decidesto send a request 1040, the user is provided with a form in which theuser may indicate: the file's name, whether the file is needed forbusiness or personal use, whether the file is needed urgently or noturgently, and any other comments the user may wish to enter. When theclient server is set for this particular environment, e.g., for aparticular company having users computers 830-850, certain rules can becoded into the client server. For example, one rule may be whether afolder for personal use may or may not be allowed to be installed on anyof the users computers. Another rule may be, for example, that any filefor personal use must be stalled, while any urgent file for business usecannot be stalled. In this manner, when a request is arrived at theclient server, it may be handled automatically without the interventionof a technician.

Another feature of the invention relates to the programs that may run onthe users computers 830-850. According to this feature, each or aselected ones of users computers is equipped with one or both of anintrusion detection program 1025 and a scanner 1026. The intrusiondetection program 1025 continuously monitors operation of selectedprograms and sends the findings to the client server 800 for monitoringand handling, as discussed above with respect to, for example, element1090. The scanner 1026 is any commercially available malicious codescanner. The scanner 1026 is kept updated by the client server 800, andit sends any detection information to the client server 800 formonitoring and handling.

Another embodiment of the invention is depicted in FIG. 11. In FIG. 11,elements noted in a box having double thick/thin border lines areperformed by the inventive user client software—referred to herein asthe user computer; elements noted in a box having double-even borderlines are performed by a policy server; and elements indicated in a boxhaving a single border line are performed by a client server. In oneillustrative implementation, an organization would have severalcomputers running the client software and monitored by the clientserver, which also resides within the organization. The client servercommunicates with the policy server over a network, such as theinternet. The policy server may communicate with other client servers ofother organizations.

When a new file 1100 is loaded onto a user computer, the computer checksto see whether the file is listed on the black list, 1105, i.e., a listof forbidden programs. If the file is listed on the black list, a rejectmessage, 1110, is issued and the file is forbidden from the computer.Optionally, a message is also sent to the policy server, 1115, so thatthe policy server may be updated to include a policy regarding thisfile. If the file 1100 is not on the black list 1105, then the computerchecks whether the file is listed on a white list, 1120, i.e., a list ofapproved files. If the file 1100 is listed on the white list, then thefile is allowed to be installed, 1125. As the file is running on thecomputer, an intrusion detection system, IDS 1130, and a virus scanner1135, continuously run on the computer and sends relevant information tothe dashboard 1140. The dashboard, 1140, enables a technician to monitorthe computers running under the client server's supervision and toprotect those computers from unwanted actions. Additionally, thedashboard 1140 may send relevant information to the policy server 1115to enable the third party server to update its policy rules.

If the file 1100 is not listed on the white list, 1120, then the file isplaced in a buffer zone 1145, which may be implemented as avirtualization system described above. As noted above in describing abuffer zone and a virtualization system, the file is allowed to executea limited space of operations. For example, the file may not be allowedto modify any trusted files and may also be prevented from accessing theinternet.

At any time, an authorization request 1150 may be sent from the computerto the system server, requesting an authorization to allow the file torun as a trusted file with full privileges on the user computer. Whensuch a request is received, the system server performs a scan, 1155, tocheck whether the file contains any malicious or harmful code. If itdoes, a reject message, 1110, is issued and the request is refused. Ifthe scan determines that the file is safe, the system may proceed eithermanually, 1160, or automatically, 1165. Whether the system proceedsmanually or automatically may depend on the system's design, theavailable resources, and/or the data the user includes in theauthorization request.

If the system proceeds manually, a determination can be made whether theresponse can slow 1175 or needs to be rapid 1170. For example, if theauthorization request includes an indication that the file is needed forbusiness purpose and is needed immediately, a rapid response, 1170, maybe processed. On the other hand, if the installation is for personaluse, the request may be processed under slow 1160. One option under therapid response 1170 may be to approve the installation, 1180. Anotheroption is to send the request to a system administrator for a review,1185. The system administrator's response, 1190, may be a refusal, 1110,an approval, 1180, or a stall, 1195.

Under either a slow 1175 or auto 1165 process, the system may proceed asfollows. A time stamp is generated to indicate the time that the requestwas made. Then the request is stalled 1195, i.e., the request is parkedfor a preset or variable time period. After the time period has elapse,an updated scan, 1194, is performed. As can be understood, this time thescanner may be updated and may include indicators for new malicious codethat was discovered during the time the request was parked. If the filehas not successfully passed the updated scan, the request is rejected.If the file has successfully passed the updated scan then an approval isprovided.

In all cases where the request is approved, a decision, 1196, may bemade whether the file should be installed in the requesting computeronly or on all served computers, When a decision is made to install onall computer, the decision may be carried out by either actuallyinstalling the file on all of the served computers or by simply addingthe identity of the file to the white list of all of the servedcomputers, so that whenever one of the served computers attempts toinstall the file, the operation would be successful as the file will beidentified as a trusted file.

One method of updating the black and white lists of the served computerscan be installed as follows. When a new decision is made at the policyserver 1115 to update the black list, white list or both, an indicationis sent to the client server, which may first run the message through acategory filter 1112. The category filter can organize the files undercategories such as, for example, audio, video, pier-to-pier, etc. Thecategories may be per-programmed by the vendor, or may be modifiable bythe user of the client server. From there the process may proceedautomatically 1114 or manually 1116. Using manual operation, 1116, aprofessional Information Technology technician can approve, disapprove,or modify the indicated changes to the black and white lists. Theindicated changes may also be passed through a client policy server. Theclient policy server may have different criteria for deciding on blackand white listing, to enable a specific client company to reflect itsbusiness policies in the policy server criteria. For example, aparticular company may have a policy that no computer games should beallowed to be run on the company's computers. This company policy may bereflected in the client policy server 1118 so that even if a file of acomputer game is approved by the policy server 1115 to be place on thewhite list as being trusted and free of malicious code, the clientpolicy server 1118 may nevertheless place that file under the black listto prevent its installation.

A particular implementation of the virtualization feature of theinvention will now be described with reference to various examples. Inthese examples, it is assumed that the system is running in avirtualized mode.

In this embodiment, a virtual directory is composed using the path:

-   -   Path A: C:\Virtual\[vid]\[drive]_[file_path]

In Path A, [vid] is a VirtualID returned by the high-level algorithms.It is an arbitrary string that can be anything, for example, the uniqueidentifier of the virtual environment in which the process is running.The [drive] is the drive identifier, where colon, “:”, is replaced byunderscore, “_”. For example, drive identifier “C:” is converted to“C\V_”. The [file_path] is the rest of the path. For example“\WINNT\SYSTEM32\TOTO.ABC”. To demonstrate, in order to virtualize PathB:

Path B: C:\WINNT\SYSTEM32\TOTO.TXT

the I/O operation is redirected to:

Path C: C:\Virtual\VID\C_\WINNT\SYSTEM32\TOTO.TXT

Of course, more than one virtual directory can be created, e.g., VID1,VID2, etc. In this manner, it is possible to run different programs,each in its own environment without the ability to contaminate thecomputer. A feature of the subject invention is that by simply deletingthe virtual directory one is able to return the computer to its originalcondition regardless of what program was running and what objects werecreated in the virtual directory.

During virtualized operation it is imperative to keep track of existing,created and deleted files in the real and virtualized directories.Therefore, what an inquiry regarding a file is received, i.e.,VirtualFS_FileExists, the system returns TRUE if the file exists in thevirtual directory or if both of these conditions apply: the file existsin the real directory and there is no such file with an extension“.$deleted” in the virtual directory. The “.$deleted” extensionindicates that a previous virtualized delete operation has beenperformed, as explained more fully below.

Various operations in the virtualized mode requires the system to comy afile from the real directory to the virtualized directory. The copyoperation, VirtualFS_CopyRealToVirtual, is implemented by performing thesteps: i. recreate each sub-directory; ii. for each sub-directorycreated, copy the NTFS rights and flags of the directory (Owner, etc);and iii. copy the file itself, along with its rights (Owner, etc). Forexample, to virtualize “C:\WINNT\SYSTEM32\Toto.txt”, recreate first“C:\Virtual\VID\C_” if it doesn't exist, then “C:\Virtual\VID\C_\WINNT”,then “C:\Virtual\VID\C_\WINNT\SYSTEM32” and then copy the file itself“C:\Virtual\VID\C_\WINNT\SYSTEM32\Toto.txt”.

As noted above, during virtualization, various operations areimplemented by system call interception of File I/O requests. Suchoperations are, e.g., read, write, delete, rename, create, andenumerate. These operations are exemplified as follows.

VirtualizeFsRead:

Check if file exists in the virtual directory.

-   -   If it does, redirect the file name of the I/O operation to the        virtual directory.    -   If it doesn't, leave the call unchanged.        VirtualizeFsWrite:

Check if file exists in the virtual directory.

-   -   If it does, redirect the file name of the I/O operation to the        virtual directory.    -   If it doesn't, perform VirtualFS_CopyRealToVirtual on the real        file into the virtual directory, and modify the file name of the        I/O operation to that of the virtual directory.        VirtualizeFsDelete:    -   If VirtualFS_FileExists(file)==FALSE, return FILE_NOT_FOUND.        This is necessary because of the check of special extension        “.$deleted”! That is, a check is first made to see whether a        request to delete this file was already executed. That is, if a        check whether the file exists finds that the only file with that        name has a “.$delete” extension, it means that this file doesn't        exists anymore, as a virtualized delete request has already been        executed.    -   If file exists in the real directory only, create an empty file        in the virtual directory, bearing the same name+extension        “.$deleted”. Return SUCCESS without forwarding the call to the        OS.    -   If file exists in the virtual directory only, erase it.    -   If file exists in both the virtual and the real directories,        perform the two above actions (but returning SUCCESS only if        both operations succeeded). Note that just deleting the file        from the virtual directory is insufficient because if we just        delete the virtual file from the virtual directory, then next        time there's a listing requests, the virtualization program will        not know to hide the corresponding file in the real directory        and it will show it to the requesting program. Therefore, we        must create a “.$delete” indication in the virtual directory to        prevent showing the real file.        VirtualizeFsRename (SourceFile, TargetFile):    -   If VirtualFS_FileExists(SourceFile)==FALSE, return error:        FILE_NOT_FOUND.    -   If VirtualFS_FileExists(TargetFile)=TRUE, return error: (same        error RENAME returns in this case, e.g., “file (TargetFile)        already exists. Do you want to replace (TargetFile) created        mm/dd/yy with this (TargetFile)?)    -   If source file exists only in the virtual directory:        -   Rename the file in the virtual directory, i.e., copy it but            name it with the new target name.    -   If the source file exists only in the real directory:        -   VirtualFS_CopyRealToVirtual(Real Source File->Virtual            Destination File)        -   Call VirtualizeFsDelete(SourceFile) so that the real source            file won't be visible in the virtual directory's listing            anymore.    -   If source file exists in the virtual and real directories:        -   Rename the file in the virtual directory.        -   Call VirtualizeFsDelete(SourceFile) so that the real source            file won't be visible in the virtual directory's listing            anymore.            VirtualizeFsCreate:    -   If file does not exist in the virtual nor the real directory:        -   Redirect the file's name into the virtual directory, i.e.,            the file is created in the virtual directory only.        -   In all cases, if the OS operation is successful, delete the            file with the same name+“.$deleted”, if it exists in the            virtual directory.            VirtualFsEnum:    -   Return a listing made of the two directories: listing of the        real directory and listing of the virtual directory.    -   For each file:        -   If the same file exists in the virtual and the real            directories, it is the virtual file that needs to be            displayed.        -   During the listing, avoid displaying “.$deleted” files, as            well as the files that they accompany (i.e: if            NOTEPAD.EXE.$deleted exists, avoid displaying NOTEPAD.EXE            and NOTEPAD.EXE.$deleted).        -   On the other hand, if in the virtual directory there is a            file FILE.EXE.$deleted and a file FILE.EXE, the virtual file            FILE.EXE is still displayed. In other words, the “.$deleted”            only applies to files that exist in the real directory. But            it does not influence the listing of files from the virtual            directory.

Example 1

If the Real directory contains:

-   -   REAL1.EXE    -   REAL2.EXE    -   REAL3.EXE        And the Virtual directory contains:    -   VIRTUAL1.EXE    -   VIRTUAL2.EXE    -   REAL2.EXE.$DELETED        Then the Virtualized listing should be:    -   REAL1.EXE    -   REAL3.EXE    -   VIRTUAL1.EXE    -   VIRTUAL2.EXE        (REAL2.EXE disappeared).

Example 2

If the Real directory contains:

-   -   FILE1.EXE (10 bytes)    -   FILE2.EXE (20 bytes)    -   FILE3.EXE (30 bytes)        And the Virtual directory contains:    -   FILE1.EXE.$DELETED    -   FILE1.EXE (40 bytes)    -   FILE2.EXE (50 bytes)    -   TOTO.EXE (60 bytes)        Then the Virtualized listing should be:    -   FILE1.EXE (40 bytes)    -   FILE2.EXE (50 bytes)    -   FILE3.EXE (30 bytes)    -   TOTO.EXE (60 bytes)

The invention is described herein with reference to particularembodiments thereof which are exemplified in the drawings. It should beunderstood, however, that the various embodiments depicted in thedrawings are for illustration only and may not limit the invention asdefined in the appended claims. Additionally, while the invention hasbeen described with reference to particular embodiments thereof, it isnot limited to those embodiments. Specifically, various variations andmodifications may be implemented by those of ordinary skill in the artwithout departing from the invention's spirit and scope, as defined bythe appended claims.

The invention claimed is:
 1. A computerized method of managing acomputer's operation in a computer having a real directory, comprising:causing the computer to create a virtual directory; monitoring operationof a program; when it is determined that the program should not be runon an unlimited trusted mode, causing the computer to: when the programattempts to delete a named file, performing the operations: checkingwhether a delete operation on the named file has already been executedand, if so, returning a file not found indication; otherwise: if thenamed file exists in the real directory only, creating a deletedindicator and returning a success indication, if the named file existsin the virtual directory only, erasing the named file, and if the namedfile exists in both the real and virtual directories, creating a deletedindicator, erasing the named file from the virtual directory, andreturning a success indication; and, further comprising causing thecomputer to: intercept a disallowed operation request sent from theprogram to the computer's operating system; and, perform one of: executethe operation request without providing it to the operating system; or,modify the operation request and provide the modified operation requestto the operating system; send to the program an indication that thedisallowed operation request has been performed as requested by theprogram.
 2. A computerized method of managing a computer's operation ina computer having a real directory, comprising: causing the computer tocreate a virtual directory; monitoring operation of a program; when itis determined that the program should not be run on an unlimited trustedmode, causing the computer to: when the program attempts to rename anamed file, performing the operations: if the named file exists in thereal directory only, copying the named file into the virtual directory,renaming the named file in the virtual directory, and generating adeleted indicator for the named file, if the named file exists in thevirtual directory only, renaming the named file, and if the named fileexists in both the real and virtual directories, renaming the named filein the virtual directory, generating a delete indicator for the named,and returning a success indication; and, further comprising causing thecomputer to: intercept a disallowed operation request sent from theprogram to the computer's operating system; and, perform one of: executethe operation request without providing it to the operating system; or,modify the operation request and provide the modified operation requestto the operating system; send to the program an indication that thedisallowed operation request has been performed as requested by theprogram.
 3. A computerized method of managing a computer's operation ina computer having a real directory, comprising: causing the computer tocreate a virtual directory; monitoring operation of a program; when itis determined that a program should not be run on an unlimited trustedmode, causing the computer to: when the program issues a file inquiry,returning a true indication if: the file exists in the virtualdirectory; or the file exists in a real directory and no indication thata previous virtualized delete operation has been performed is found;and, further comprising causing the computer to: intercept a disallowedoperation request sent from the program to the computer's operatingsystem; and, perform one of: execute the operation request withoutproviding it to the operating system; or, modify the operation requestand provide the modified operation request to the operating system; sendto the program an indication that the disallowed operation request hasbeen performed as requested by the program.
 4. A computerized method ofmanaging a computer's operation in a computer having a real directory,comprising: causing the computer to create a virtual directory;monitoring operation of a program; when it is determined that theprogram should not be run on an unlimited trusted mode, causing thecomputer to: when the program attempts to delete a named file,performing the operations: checking whether a delete operation on thenamed file has already been executed and, if so, returning a file notfound indication; otherwise: if the named file exists in the realdirectory only, creating a deleted indicator and returning a successindication, if the named file exists in the virtual directory only,erasing the named file, and if the named file exists in both the realand virtual directories, creating a deleted indicator, erasing the namedfile from the virtual directory, and returning a success indication;send to the program an indication that the disallowed operation requesthas been performed as requested by the program; and, further comprisingcausing the computer to: for each subsequent program that should not beallowed to run on the computer on an unlimited mode, create a subsequentvirtual directory.
 5. The computerized method of claim 4, furthercomprising causing the computer to delete at least one subsequentvirtual directory to return the computer to its original condition.
 6. Acomputerized method of managing a computer's operation in a computerhaving a real directory, comprising: causing the computer to create avirtual directory; monitoring operation of a program; when it isdetermined that the program should not be run on an unlimited trustedmode, causing the computer to: when the program attempts to rename anamed file, performing the operations: if the named file exists in thereal directory only, copying the named file into the virtual directory,renaming the named file in the virtual directory, and generating adeleted indicator for the named file, if the named file exists in thevirtual directory only, renaming the named file, and if the named fileexists in both the real and virtual directories, renaming the named filein the virtual directory, generating a delete indicator for the named,and returning a success indication; send to the program an indicationthat the disallowed operation request has been performed as requested bythe program; and, further comprising causing the computer to: for eachsubsequent program that should not be allowed to run on the computer onan unlimited mode, create a subsequent virtual directory.
 7. Thecomputerized method of claim 6, further comprising causing the computerto delete at least one subsequent virtual directory to return thecomputer to its original condition.
 8. A computerized method of managinga computer's operation in a computer having a real directory,comprising: causing the computer to create a virtual directory;monitoring operation of a program; when it is determined that a programshould not be run on an unlimited trusted mode, causing the computer to:when the program issues a file inquiry, returning a true indication if:the file exists in the virtual directory; or the file exists in a realdirectory and no indication that a previous virtualized delete operationhas been performed is found; send to the program an indication that thedisallowed operation request has been performed as requested by theprogram; and, further comprising causing the computer to: for eachsubsequent program that should not be allowed to run on the computer onan unlimited mode, create a subsequent virtual directory.
 9. Thecomputerized method of claim 8, further comprising causing the computerto delete at least one subsequent virtual directory to return thecomputer to its original condition.